Many systems that are designed for military and commercial use include hardware devices that are embedded as part of a computing platform. In development and production of such embedded hardware devices, the hardware utilized by these devices must be tested. And any internal software within the devices must be tested and debugged. The software testing and debug process is difficult due to the lack of tools to test embedded hardware.
FIG. 2 (prior art) provides a block diagram for an example environment 200 of prior solutions for testing embedded hardware devices. The platform 202 represents a computing platform within which an embedded hardware device will operate. The hardware bus 206 represents the bus through which the hardware device will communicate with the platform processing system 204. The hardware test device 208 represents the embedded hardware device being tested. One example of a platform 202 is a computing platform that includes a central processing unit (CPU), program storage (e.g., program storage provided by memory integrated circuits or hard disk storage) connected to a motherboard, and a hardware bus 206, such as a VME bus. Currently, VME (VersaModule Eurocard) buses are widely used in industrial, commercial and military applications. A wide variety of hardware devices have been and can be designed for use with VME enabled CPUs and computing platforms. The hardware devices, for example, can take the form of processing cards that attach to VME slots within the VME computing platforms.
As stated above, one significant problem in developing embedded hardware devices for computing platforms, such as VME computing platforms, is debugging the hardware device in operation within the computing system. Prior attempts to solve this testing problem have primarily focused on developing custom, hardware-specific debug tools that are designed specifically for the platform, the hardware bus and the embedded hardware device involved in the project. Looking back to FIG. 2 (prior art), block 210 represents such a prior debug tool. The custom, hardware-specific debug tool 210 is developed along with the embedded hardware test device 208, and the custom, hardware-specific debug tool 210 is used to communicate with the processing system 204 to test and debug the embedded hardware test device 208. The problem with this approach is the time and resources required to develop and customize a new debug tool for every embedded hardware device developed.
There are a variety of existing tools that can be utilized by developers; however, they are designed for particular platforms and do not solve this hardware debug test problem. Mathematical tool vendors provide programs for mathematical analyses, such as MATLAB offered by MathWorks, but such programs do not directly address embedded hardware debug. Some Single Board Computer (SBC) vendors, like General Micro-Systems (GMS), provide simple bus access programs, like VMExpress, but do not provide a tool directed to embedded hardware debug. Bus analysis companies, like Vmetro, provide bus analyzer hardware and software to observe bus traffic but no means to perform complex embedded hardware bus based programming is provided. Operating system vendors, such as WindRiver, supply debugging mechanisms limited to their specific operating systems. Instrumentation vendors, like National Instruments, provides tools to control instruments but again do not provide tools to solve embedded hardware debug. In short, the tools available do not provide a multi-platform tool specifically directed to embedded hardware device debug operations.